home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17161 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: port4.lightlink.com!user
  2. From: doug@lightlink.com (Doug Wyatt)
  3. Newsgroups: comp.lang.c++
  4. Subject: STL: tiny vectors
  5. Date: Sat, 13 Apr 1996 22:42:38 -0400
  6. Organization: none
  7. Message-ID: <doug-1304962242380001@port4.lightlink.com>
  8. NNTP-Posting-Host: port4.lightlink.com
  9.  
  10. I'm relatively new to the STL.  I'm experimenting with widespread use of
  11. the vector<T> class and have run into a problem.
  12.  
  13. Many of my vectors are rather small, 2-10 small elements.  The
  14. implementation of allocator (HP via Metrowerks CodeWarrior) implements
  15. memory in chunks of no less than 4096 bytes.  When I have many arrays
  16. under 100 bytes, this adds up to a lot of wasted memory.
  17.  
  18. I started writing code to make my algorithms multi-pass so I can know in
  19. advance how large a vector is to be, and call reserve(), but it seems this
  20. really shouldn't be necessary.
  21.  
  22. Another thing I've toyed with is using my own allocator which uses
  23. malloc() and free() instead of the global operators new and delete.  That
  24. way I can use realloc() to shrink a vector.  I suppose this will work but
  25. it occurs to me that  if I allocate 3 vectors, put a few elements into
  26. each of them, then shrink them all, those three memory blocks will still
  27. be 4K apart, without the possibility of allocating another 4K vector in
  28. the memory between them.  So ultimately memory gets fragmented this way
  29. anyhow.
  30.  
  31. I have a book that claims the default allocator should be using a page
  32. size of 512, so perhaps making my own allocator use 512 would be a simple
  33. enough solution, though for many -- but not all -- of my vectors this
  34. would still result in the array being 4 times larger than necessary.
  35.  
  36. Should I be using another container besides vector?  I thought about using
  37. a list but I'd like to be able to retain fast random access into my
  38. containers.
  39.  
  40. Have I overlooked an STL feature which addresses this issue?
  41.  
  42. Thanks in advance for any suggestions.
  43.  
  44. Doug
  45.  
  46. ---
  47. Doug Wyatt                          music software
  48. doug@lightlink.com                
  49. http://www.lightlink.com/doug
  50. "It is a miracle that curiosity survives formal education."
  51. - Albert Einstein
  52.